The invention relates to computer systems, and more particularly to a method and mechanism for implementing and generating messages based on HL7 V3 Health Level Seven (HL7) Version 3 (V3) standard.
Computing systems often use the concept of messaging to communicate and exchange information between different systems or applications. Before the source and destination systems can adequately communicate using messages, the two systems should clearly agree upon the semantics and format of the messages and the information to be exchanged in the messages.
Specialized systems and applications may have a particular need to employ standardized or agreed-upon information models to structure and format messages. For example, consider a data item “observation” that may be exchanged between applications in the healthcare field. This data item may generically refer to any number of data formats, such as a numerical value, image, text, mixed values, etc. Because this data item may potentially be of such different formats, to adequately communicate this information, the source and destination systems that plan to exchange this information type may necessarily need to agree upon the semantics and format of the data.
In the field of healthcare applications, the Health Level Seven organization of Ann Arbor, Mich. has promulgated a standard/protocol known as HL7 to be used in the healthcare domain. HL7 is associated with a messaging standard that enables disparate healthcare applications to set of clinical and administrative data. The HL7 Reference Information Model (RIM) is the basis of the HL7 V3 standard. The RIM is a pictorial representation of the clinical data supported in the HL7 standard expressed in UML notation. Thus, the HL7 RIM is a shared information model between domains and is the model from which domains will create messages.
FIGS. 1a and 1b pictorially depict an example for managing location information in a clinical setting. Objects used in a diagram are specialization of objects defined by RIM. The data model shown in these figures describe the attributes, entry points, and relationship cardinality for data objects relevant to clinical information to be maintained and exchanged for managing location information. For example, Box 104 in FIG. 1a “A Location” corresponds to a role of a Location. Element 105 (participation) connects Role to an Act (Box 102). Box 104 in FIG. 1a provides the entry point for Box 106 in FIG. 1b. An HL7-based message relating to the action of managing location would serialize some or all of the information provided in this information model in a “hierarchical message definition” (HMD) that is a format independent method for encapsulating the information. Another HL7 methodology, Implementable technology specification (ITS) will define how format independent representation of a message defined by HMD can be converted to format specific message representation (e.g. Extensible Markup Language (XML), Common Object Request Broker Architecture (CORBA). Since both the sender and receiver would presumably have a working knowledge of HL7 V3 specifications, each party would be able to encrypt and decrypt a message in this format.
A recent release of HL7 (version 3) has defined the XML architecture as the preferred way of exchanging of clinical documents. The encoding for this standard is based on XML Schemas included in the HL7 version 3 specification (ITS) and its semantics are defined using the HL7 RIM. More information about the HL7 specification can be found at “h17.org.”
Possible approaches for building instances HL7 messages include using generic XML authoring tools (e.g. DOM API) or using tools that allow XML to be generated from database schemas with further transformation of the XML by means of XSLT into HL7-defined formats. The drawback with generic tools is that a developer is required to manually build the HL7 messages while knowing and understanding the exact requirements of the HL7 specifications. Moreover, before a developer can build an HL7 message, this approach necessarily requires the developer to also be familiar with XML. The drawback with using tools to allow XML to be generated from the database schemas is complex style sheet transformation that also presumes intimate knowledge of XML.
Accordingly, the present invention provides an improved method and system for implementing and building messages, such as HL7-based messages without knowledge by an application developer of specific format (e.g., XML) of a message. In an embodiment, messages are constructed in a format-independent manner, in which a message is built by instantiating and linking Java™ classes. Metadata for the message specifications are used to construct the Java class libraries. Signature of the classes automatically cause the messages to be constructed with correct syntax, structure, and restrictions. Thus, the correctness of the constructed messages to a large extent can be enforced at compile time. Moreover, a developer can construct a specification-specific message without having to know XML. Further details of aspects, objects, and advantages of the invention are described below in the detailed description, drawings, and claims.